/retest

flaky subspace test : https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/test-platform-results/pr-logs/pull/codeready-toolchain_host-operator/1149/pull-ci-codeready-toolchain-host-operator-master-e2e/1896912619076325376/build-log.txt

looking at it

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: fbm3307, MatousJobanek, metlos, mfrancisc

The full list of commands accepted by this bot can be found here.

The pull request process is described here

it looks like we might have a flaky unit test also:

     metric.go:40: 
            	Error Trace:	/home/runner/go/pkg/mod/github.com/codeready-toolchain/toolchain-common@v0.0.0-20250303095208-d379ee86d136/pkg/test/metrics/metric.go:40
            	            				/home/runner/work/host-operator/host-operator/controllers/usersignup/usersignup_controller_test.go:4907
            	Error:      	Not equal: 
            	            	expected: 0xd
            	            	actual  : 0xc
            	Test:       	TestRecordProvisionTime/should_be_in_histogram

will take a look at it as well.

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

it looks like we might have a flaky unit test also:

     metric.go:40: 
            	Error Trace:	/home/runner/go/pkg/mod/github.com/codeready-toolchain/toolchain-common@v0.0.0-20250303095208-d379ee86d136/pkg/test/metrics/metric.go:40
            	            				/home/runner/work/host-operator/host-operator/controllers/usersignup/usersignup_controller_test.go:4907
            	Error:      	Not equal: 
            	            	expected: 0xd
            	            	actual  : 0xc
            	Test:       	TestRecordProvisionTime/should_be_in_histogram

will take a look at it as well.

@mfrancisc , its because it checks the sequence too... Probably using assert.elementsmatch should work rather than require.equal

Not sure I'm following.

TBH to me it seems that the bucket nr 13 had 12 as value. So basically it expected 13 but it got 12. Which seems like a timing issue when using the prometheus client.

To me the only way to make the tests 100% reproducible would be to create a mock/stub instead of using the prometheus library. Thus the test would only assert that expected function were called with expected values.

Codecov Report

Attention: Patch coverage is 72.72727% with 12 lines in your changes missing coverage. Please review.

Project coverage is 79.67%. Comparing base (a7713fb) to head (5e18a51).
Report is 1 commits behind head on master.

@@            Coverage Diff             @@
##           master    #1149      +/-   ##
==========================================
- Coverage   79.71%   79.67%   -0.05%     
==========================================
  Files          82       82              
  Lines        8203     8245      +42     
==========================================
+ Hits         6539     6569      +30     
- Misses       1471     1480       +9     
- Partials      193      196       +3